% !TEX root = main.tex

\section{Towards Heterogeneous Model Driven Security}
\label{sec:heterogeneity}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.8\textwidth]{./figures/trend}
	\caption{Evolution Trend of Model Driven Security}
	\label{fig:trend}
\end{figure}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.9\textwidth]{./figures/heterogeneity_v02}
	\caption{Heterogeneous Y-Model}
	\label{fig:heterogeneity}
\end{figure}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.8\textwidth]{./figures/meta-modeling}
	\caption{Example of heterogeneous modeling}
	\label{fig:example}
\end{figure}

From \tab \ref{tab:comparison} and as discussed in \sect \ref{sec:criticism}, we
are able to deduce the evolution trend of Model Driven Security, illustrated in
\fig \ref{fig:trend}.

The early \mds methodologies, \eg \emph{UMLsec} and \emph{secureUML}, apply \UML
profiles to model system requirements. Regarding security concerns, these
methodologies always concentrate on one specific aspect, \eg access control.
Later researchers evolve \mds by developing tailored \dsl~s designed
for modeling security properties at a generic security requirement metamodel
level. The general security metamodel can be specialized by several extensions
which form multiple security concern metamodels, \emph{c.f. ModelSec}.

However, in our opinion, it is hard to develop a general \dsl to model multiple
security concerns simultaneously due to their huge diversity. For better
modeling and analysis capability, each security concern needs a specific
tailored \dsl designed just for it, as shown in the dashed rectangle in \fig
\ref{fig:trend} (a forecast to the future). We call this \emph{heterogeneity}
and it comes from two sources: the business model has usually to mix several
patterns and functionalities (\eg business rules expressing knowledge, but also
its persistency); and the security concerns are also multiple in nature:
authenticity, integrity, access control, delegation of responsibility, among
others. If a development methodology does not reflect this very nature of such
systems, then designing and deploying such systems needs too much effort and is
too time and cost consuming.

To tackle the challenges, we propose the \emph{Heterogeneous Y-Model} depicted
in \fig \ref{fig:heterogeneity}, an enhanced model with heterogeneity at its
core, as a potential paradigm for future \mds: both business and security
concerns should be modeled at the best level of abstraction, by limiting
accidental complexity due to the formalisms employed. The use of \DSL{}s is the
primary artifact for properly capturing heterogeneity. In particular, security
concerns should not be integrated within the same metamodel, but should be
distributed among several \DSL{}s, each one taking care of one specific concern.

\fig \ref{fig:example} depicts an schematic overview of this approach, which
fully benefit from their associated benefits \cite{B:Kleppe:2009}: visual model
specification closely related to the domain notations; \DSL{}s semantics and
composition expressed with transformations, which enable automation and reuse,
allowing engineers and experts to perform the associated analysis using the
existing technology in the domain \cite{B:Kelly-Tolvanen:2008}.

Although this approach addresses in a better fashion the crucial dimension of
heterogeneity in business and security concerns, which is a major advantage for the design, it
has several technical difficulties whose resolution should be carefully studied
to fulfill its promises. We foresee two crucial challenges related to the fact
that security concerns are spread over several models. First, it hinders its
comprehension by the experts since they need to deal with several models at the
same time, but this drawback is balanced by their narrowed focus. Second, it
requires powerful composition operators for creating models that amalgamates all
security aspects, which is crucial for later phases: whereas it becomes possible
to analyze security properties independently, enforcement and code generation
encompass all security aspects that need to be modeled before reaching platform
code. Third, it complicates keeping all models synchronized: all security models
somehow share some common information, which implies security models updates
along time and according to business models evolutions; but more importantly,
tracking back errors within the multiple security models after feedback is
obtained from analysis occurring in subsequent layers becomes more complicated.



